Virtual Router Redundancy Protocol, or VRRP, is a networking protocol that enables a group of physical Layer 3 (i.e., Internet Protocol (IP)) routers connected to a LAN (local area network) segment to act in concert as a single, virtual router. One router in the VRRP group, known as the “master” or “active” router, serves as the default gateway for hosts on the LAN segment and actively routes unicast data traffic to/from the hosts. Other routers in the VRRP group, referred to as backup routers, operate in a backup mode and do not route any data traffic. If the master router fails, VRRP allows the routers in the VRRP group to automatically elect one of the backup routers as a replacement for the failed master router (and thus become the new VRRP master). Data traffic is then redirected through the newly elected master router, thereby enabling routing in the LAN segment to continue uninterrupted. An extended version of VRRP, known as VRRP-E, is available on routers developed by Brocade Communications Systems, Inc.
In scenarios where the routers that are connected to a LAN segment are multicast-capable (in other words, they support L3 multicast routing under the PIM (Protocol Independent Multicast) or other multicast protocol standards), one router in the set of multicast-capable routers is typically elected as a designated forwarder (DF) for multicast traffic. The DF is responsible for forwarding all multicast traffic to the LAN segment, which prevents duplicate multicast packets from reaching that segment through different routers in the set.
One issue that exists in these scenarios is that, in prior art routers, the election of the DF is based on static criteria (e.g., a preconfigured or default DF priority value for each router and/or interface IP address) that do not take into account the actual routes installed into each router's multicast and unicast routing tables. This is problematic because multicast forwarding requires an RPF (reverse path forwarding) check in which the route to the multicast source is looked up in a multicast routing table and, if absent, looked up in a unicast routing table. If the route is absent from both tables, the multicast packets are not forwarded. Thus, if the elected DF does not have its routing tables populated with a route to the source (due to, e.g., unstable paths to the source or other network connectivity issues), the RPF check will fail, causing multicast traffic to be inadvertently dropped.
Another issue is that, in the scenario where a set of multicast-capable routers connected to a LAN segment are also part of the same VRRP group, the election of the VRRP master router and the election of the DF are performed using different and separate mechanisms. As noted above, DF election is performed based on a DF priority value and, in the case of a tie with respect to the DF priority value, is performed based on interface IP address. However, the election of the VRRP master is performed based on a separate virtual router ID (VRID) priority value that is specific to VRRP. This means that the elected VRRP master can be different from the elected DF, which causes the unicast and multicast forwarding paths to be different. This, in turn, results in inefficient forwarding and can make troubleshooting more difficult.